home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Magnum One
/
Magnum One (Mid-American Digital) (Disc Manufacturing).iso
/
d20
/
tick207.arc
/
TIC2NOTS.DOC
< prev
next >
Wrap
Text File
|
1991-02-08
|
16KB
|
349 lines
Betatic.doc
Tick 1.31 -
* Fixed a minor bug that could allow an invalid AKA to be
used in rare cases.
* First attempt at instituting the SECONDARY areas. If you
ever followed the AREA name in the TIC.CFG file with something,
you might have encountered the message about not finding the
secondary area. That was a result of code that was only par-
tially implemented. Now to explain what a secondary area is, and
how it works:
AREA c:\dir\dir2\boo SOFTDIST R13DIST
The line above is the start of an area block that declares a
primary area tag of SOFTDIST, and a secondary area called
"R13DIST". R13DIST MUST be defined as the primary tag of another
AREA block.
What will happen is this: If a file is received in
SOFTDIST, the file will be echoed to the nodes listed under
SOFTDIST (with a file-echo-tag of SOFTDIST), and to the nodes
listed in R13DIST (with a file-echo-tag of R13DIST). Files
received in R13DIST will NOT echo into SOFTDIST, unless SOFTDIST
is also a secondary area for R13DIST.
Files entering your node will be tossed to the SECONDARY
area's toss-to directory if a secondary area is defined. (It can
be the same as the primary area's directory.) The exception to
this is if STOPDUP is active. In that event, if the file has
been seen in the secondary area but not in the primary area, it
will toss to the primary area.
If STOPDUP is active, echo will be suppressed in any area
that has already seen the file. If the file has been seen in the
primary, but not the secondary area, only the secondary area will
receive the outbounds, and vice-versa. If the file has been seen
in BOTH areas, the inbound will be failed (renamed to *.BAD).
The Seenby's for BOTH areas will appear in all the generated
TICs. If the same node is listed in both primary and secondary
areas, the file will go to that node in the primary area only.
The code is not re-entrant. If the secondary area has its
own secondary area, a file sent in the primary area will not echo
all the way down to the 3rd area. This prevents circular defini-
tions.
So what is it good for? Several things that I can think of,
and probably a few more I haven't. In the SDS, only selected
nodes are given "*" capability in the national echos. Using
1
Betatic.doc
secondary areas, you could have all nodes in a region link into
SOFTDIST via the local echo R13DIST (or whatever you might chose
to call it). The local nodes can all be given "*" capability to
hatch to each other within R13DIST. The files will flow locally,
but not enter the national echo unless the RC hatches them into
that echo. You might choose to use the secondary area feature to
merge two echos locally, while maintaining individual echo feeds
for those who want or need the distinction. To do that, you'd
have the same secondary area for 2 (or more) primary areas.
Another use may come into play when pre-release is a reality.
* Please note that HATCH now asks for "release in how many
days?" That is there for pre-release, and is still disabled.
(That code is partially there in HATCH, but not yet in TICK.)
You may bypass the prompt by including the command line parameter
"/R0", to tell HATCH to release it in "0" days, (ie - NOW).
* Defined a new Files.bbs specification. %8 will print the
name of the PRIMARY area (that the file was received in) to the
Files.bbs
* Fixed the Doc file for the next release, to correct the
keyword LINEFMT to the proper form, LISTFMT.
~~~~~~~~~~~~~~~~~~~~
Tick 1.32 -
* Hopefully have closed a hole in the COPY routine where a
file could have been copied to a full disk and error not have
been reported. I wonder if this was the cause for occasions
where TIC's have been sent without the files?
* Version 1.31 of HATCH can cause some DUPs if both primary
and secondary areas are active and have a duplicated node listed
in both. This version should fix that.
* Have added support for zones 1 - 32767. This involved a
lot of changes, so look for any flaky operations.
* If you receive a pre-release file, the planned release
date should be logged.
* Tick now partially implements pre-release!!! Here's how
it works: Within an AREA block, those nodes that may receive a
pre-release file before the release date should have a "P" flag
in the flag field. When you HATCH a file, the prompt for
"Release in how many days?" is now active. If you just press
<enter>, the file is a normal file and is not delayed. If you
have a file that you want to send as a pre-release, place the
file into the QDIR directory. (QDIR should NEVER be a
2
Betatic.doc
downloadable directory). When the prompt for release days comes
up, answer with the number of days to delay. (You may bypass the
prompt by using the /Rx command line option, where "x" is the
number of days to delay. /R2 delays 2 days, /R0 is a normal
release.
If you have specified a pre-release file, then only those
nodes that have a "P" flag will get the file immediately. Please
note that only nodes that are also running TICK 1.32 or higher
should be given "P" status. Those nodes will have TIC's and at-
taches created. The TIC's will have the seenbys for all nodes
that will eventually receive the file. In addition, there will
be a "*.TOK" file also created in the HOLD directory. That file
resembles a TIC closely, but has the seenby's for the pre-release
nodes only.
Each time you run TICK 1.32+, the program will first scan
the HOLD directory for TOK files. If it finds any, it examines
them to see if the associated pre-release file is "ripe" yet.
When it is, the file is moved to the destination (downloadable)
directory, the FILES.BBS is updated, and new attaches are created
to those nodes that do not have the "P" flag.
THIS IS ONLY PARTIALLY IMPLEMENTED YET ... What I will need
to do is to provide for the case where the file is "ripe" but all
the "P" flagged nodes have not yet received the file. In that
instance, the existing file attaches will become invalid when the
file is moved. I need to write code that will look for any un-
delivered attaches for that file, and alter the FLO or MSG to
point to the proper place. Right now that hasn't been coded, so
if all "P" nodes have not had their files delivered before the
time comes, they won't get them at all.
Pre-release can be set up in two ways. Currently, in the
SDS the public echos go not only to the SDS nodes, but to the
"end-user" nodes as well. If files are to be directly pre-
released into the public echos such as SOFTDIST, then any node
that receives pre-release files in that fashion must be running
1.32 or higher, as lower numbered version will forward all files
without reservation, as will FLEA (with minor reservation). This
could still be used in this fashion if all SDS RC's decide to run
the new TICK when it's ready. The second way, and probably the
more secure way, would be to set up a separate pre-release echo
associated with each public echo. For example, PRESOFT could be
associated with SOFTDIST, PREBINK could be associated with
SDSBINK, etc. When these would be set up, the public area would
be listed as a secondary area. Then all nodes listed in the
PRExxx echo could be "P" nodes, and non-P nodes would be in the
secondary area. This way, there would be less chance of acciden-
3
Betatic.doc
tally linking to a non-prerelease node in the public echo. This
setup would not effect the normal operation of the public echos
at all.
EXAMPLE: AREA d:\prebink PREBINK SDSBINK
1:261/662 password *HP
1:135/204 passw2 HP
AREA d:\sdsbink SDSBINK
1:261/662 passw3 *H
1:266/13 passw4 C
1:132/101 passww C
In this example, you can receive normal file from 261/662 in
either PREBINK or SDSBINK. You can receive Pre-Release file from
261/662 in PREBINK. If you receive a normal file in PREBINK, all
nodes listed in BOTH areas will get it immediately. If you
receive a normal file in SDSBINK, then only those nodes in
SDSBINK will receive the file, and if you receive a pre-release
file in PREBINK, then it will be echoed to 135/204 immediately,
and will be released to the rest of the nodes when it's ripe.
NOW you should all understand why I was going to all that
bother to create the "secondary areas" stuff!
NOTE: With the addition of pre-release, it's VERY important
that the TZ environmental variable be set properly. If it isn't,
release times will be off.
KEEP IN MIND THAT THIS IS NOT YET FULLY FUNCTIONAL ... THERE
IS NO PROVISION YET FOR THE CASE WHERE A "P" NODE HAS NOT
RECEIVED THE FILE BY RELEASE DATE.
~~~~~~~~~~~~~~~~~~~~
Tick 1.33 -
* Hatch will now log the file release information to the
log.
* If you are using HATCH with the "No Wait" (/ON) option in
a batch file, HATCH will no longer loop back for a new filename
if stopdup detects a duplicate entry. It will now abort with an
error level 2.
* TICK now attempts to determine if you are running it
during a Seadog mail event, and will postpone release of a file
if there are undelivered pre-release attaches for that file al-
ready packetized.
4
Betatic.doc
* Added certain error recovery routines for the "release"
function ... previously an error would always abort the program.
~~~~~~~~~~~~~~~~~~~~~
Tick 1.34 -
* Fixed (at least one) error caused by the compiler not fol-
lowing its documented rules of precedence. This would cause
memory trashing and eventual bombing of the program.
* Added additional checks for failed closes after a write,
(Usually meaning that the disk is out of space).
* TICK and HATCH now require a TZ to be set to run. You may
either set it in the environment before calling the program(s),
or you can add it to the CFG file in the form:
TZ EST5EDT
If BOTH are set, TICK/HATCH will use the one from the en-
vironment. No test is done to see that the value you set is
valid. You can lead a horse to water ....
* Fixed the FROM line that HATCH was putting in the TOK
files. Right now the FROM line is not used there, but it's there
in case it comes in handy later.
* Added new Stopdup support ... Stopdup is now smarter. If
you do nothing, it will continue to act as before. Any dupli-
cated filenames in an area will not echo or toss if STOPDUP is
defined in the CFG.
If you add the keyword DupByCRC, and have the CRC2DUP option
active, then STOPDUP will cause TICK to test not only the NAME of
the file, but also the CRC32 of the file. A "hit" will only oc-
cur if the the CRC matches as well as the name. This will allow
same-named files to pass Stopdup if the files are different than
the one previously seen. If the older / same-named file is still
in the "toss-to" directory, it will (presently) be overwritten.
* If you choose to not set the global DupByCRC keyword,
which affects ALL areas, you can selectively still employ the new
dup-check routine in selected areas of your choice by adding a
"LOCAL DupByCRC" to the list of LOCAL lines following the AREA
definition line.
5
Betatic.doc
* Should you decide you want to use the CRC dup checking
routine in most areas, but wish to exclude a few, you may place
the DupByCRC keyword in the CFG, and add a "LOCAL NoDupByCRC"
line to the list of LOCAL lines following the AREA definition
line.
* If you decide to use the newer CRC-based DUP detection,
any DUP file lines that contain only a filename and no CRC number
(such as may exist from previously running the programs without
CRC2DUP in the CFG) will be tested by the older stopdup logic.
Barry Geller
609-482-8604
1:266/12
6
